Subject: Answers to HPR Questions

From: "Ray Bird" <[email-masked]>
Date: Thu, 12 May 94 14:19:59 EDT

The following questions about HPR were asked by Mathew Finlayson from DCL.
These are good questions and I think anyone interested in HPR will want
to know the answers.  The answers are flagged with '*'.

Ray Bird and Lap Huynh

----------------------------------------------------------------------------

1) SAPs (6.3.2)

The HPR spec explains that the decision to use a new SAP to transmit HPR LAN
traffic was taken primarily for reasons of product performance. Could you
expand on the reasons for this choice?

A simpler option would have been to send the HPR traffic in Unumbered
Information (UI) frames on the standard APPN SAP. This would have avoided the
rather untidy need to communicate the number of the HPR SAP down to the DLC
layer after XID exchange - a piece of protocol which is very LAN specific.

* The path length when using UI may be slightly longer (50 more instructions)
* then when routing directly off the SAP.  But even slightly longer can affect
* product performance.  These is the reason for the HPR SAP.  Note that products
* can implement using the APPN SAP (e.g. X'04') but sending the HPR frames UI.
* So providing the option of using a separate SAP gives the most flexability.

2) Long-lived RTP Connections (9.2.6.1)

I'm not sure that I follow the justification for having long-lived RTP
connections for Route-Setup between HPR Tower nodes (rather than sending
route-setup messages in FID2 packets as will be done if an HPR Base node
is involved).

The spec (in 9.2.6.1) suggests that this may have been done to permit HPR to
run over links without any link-level error recovery at some time in the
future. However, the protocol for Link Activation (6.2) in its discussion of
set-mode signals and especially the need for Link failure detection (6.4)
suggest that this will not be possible.

There are no obvious advantages for using RTP connections to transmit route-
setup messages since the normal RTP gains (end-to-end error recovery, fast
intermediate session routing) become irrelevant for a single hop route, whilst
HPR advantages such as path-switch are explicitly precluded due to the nature
of the long-lived connections. On the other hand, keeping a RTP connection
open for every HPR Tower-Tower link will tie up unecessary resources at both
ends and make the link-activation and route-setup protocols harder to
implement.

* Good point.  We will consider allowing Route Setup to flow as FID2.

3) Boundary Function impact on CP-CP Sessions (10.2)

A minor point - this section of the spec seems to be rather confusing and
inaccurate. It suggests that protocol conversion (between FID2 and FID5) will
be done for CP-CP session traffic. The reality is that the traffic passing
between HPR and APPN subnets will reach the appropriate CP component and be
forwarded on a different session altogether.

Perhaps this section should be either rewritten or perhaps removed altogether.

* The point trying to be made here was that the only thing that needed
* to be changed when going from APPN CP-CP session to HPR CP-CP session
* was the headers.  We will try to clarify further.

4) Timescale for the next HPR spec update

Are you able to give us any idea when we might see the next version of the
HPR spec? In Ray Bird's email of 18th January he wrote

>  * Recent changes to the format of the CV4680 have occurred such that
>  * the TG type field is no longer used to indicate HPR capability
>  * (these changes will be reflected in the next version of the document).

suggesting that significant changes may have been made to the specification
since it was last published in September 1993.

* The significant changes were distributed at the Feb. AIW.  For example,
* the change to the CV4680 format was distributed then.

We have come across problems with the HPR spec in the area of RTP connection
activation (7.2.2). Specifically - there seems to be no provision made for
failures during connection activation.

The first issue seems to occur when a connection setup NLP (one containing the
'CS' optional RTP segment) arrives at a destination node containing no
listening RTP context (this might happen if the destination node was
suffering from resource depletion). Our assumption is that the destination
node should simply drop the request, since there is no mechanism for
rejecting a connection setup message.

* Yes, if the destination node runs out of resources to process the
* Connection Setup, it can drop the request.  But if the destination
* has enough resources to accept the Connection Setup request but
* detects an error in the request itself, it must return to the
* origin node a status message with a closed bit set to indicate
* that an error was detected.
* If the request is dropped, the origin node will attempt to
* resend the CS message (with new sync in STATUS segment)
* up to K number of retries.  After K  number of retries, it will
* attempt to do a pathswitch (a pathswitch would help if the
* reason of failure is that a link(s)  breaks).  It will give up
* after the pathswitch timer times out.

If this is so, it appears to raise other issues. Presumably, the RTP
SHORT_REQ timer at the origin node will be running (since the message
contained a status request), and will time out. Next the origin node will
attempt to initiate a status exchange, which will also fail and will be
retried until the retry limit is reached. At this point, the protocol would
indicate that a path-switch should be tried. There appear to be issues with
the mechanics of this - the origin RTP context is not yet in CONNECTED state,
so it is unclear whether a path-switch is valid, or how it should be
signalled to the remote end (presumably the originating RTP must resend the
CS request, rather than just a STATUS segment).

* The pathswitch is valid because the reason for failing to receive
* the acknowledgement of the CS message might be of path failure as
* mentioned above.  Each retry while the RTP context is in CALLING
* state will carry the CS message.

Taking the scenario one step further, there seem to be problems in the
situation where the CS messages successfully reaches an RTP context in the
destination node, but the message containing the CIE segment fails to return
to the origin node. Since this message does not contain a status request,
is appears that there is a chance that this message will be lost and never
resent. (In the situation where both ends trigger a path switch, and the
destination node wins.)

* The CIE will be included along with every packet sent by the passive
* partner until the a packet is received by the passive partner with
* the locally assigned TCID (i.e., TCID assigned by the passive
* partner).  Therefore, it is not necessary to request
* status for the CIE.

Looking at the XTP specification (from which I believe that RTP draws many of
its concepts) I notice that (XTP revision 3.6, page 51) there the concept of
a 'FIRST' packet (their equivalent of an CS request) 'subsuming' an earlier
active context. Is this the sort of mechanism envisaged in RTP (ie. the
originating RTP retries the CS request with a different sync value) ?

XTP also seems to have the means of rejecting FIRST requests (with a DIAG
packet) - there seems to be no counterpart in RTP.

* RTP has similar mechanisms as described above.

(1) Route Setup Protocol (9.2)

The specification is very unclear about the mechanism by which a route-setup
reply (be it positive or negative) is directed back to the origin node.
In the case of a negative reply no RSCV is included, in the case of a
positive reply the RSCV is included, but the route-setup does not carry
information to identify the origin node.

Eventually we noticed (in the description of the route-setup GDS (A.1.15))
that the route-setup GDS variable carries a FQPCID which is recorded in
intermediate nodes along the path of the setup.  The implication is clearly
that the intermediate nodes need to remember the previous hop to direct
the reply, and also to rescue the situation should a link fail during route-
setup (ie to create and send a route-setup failure back along the path,
similar to a directed locate.)

This area is currently poorly documented, and the approach does have a couple
of drawbacks:

-     the route-setup is not a state-less process
-     the route-setup requires intermediate storage during the life of the
      request.

An alternative (more elegant?) approach might be to accumulate the RANR() on
the way out and the FANR() on the way back (reversing the current process).
This would mean that the reply could be routed by means of the RANR().  The
origin node could, in addition, run a timer to detect if the route-setup
message gets lost somewhere along its path.

* The running-a-timer-at-the-origin option was considered but the complexities
* of dynamically figuring out a suitable value for the timer (not too short but
* not too long) and the fact that there would be yet another timer in HPR,
* killed it.  The primary advantage of the intermediate nodes maintaining a
* state while waiting for the reply is that if the link fails (over which the
* the reply is to be received) the intermediate node notifies the origin
* immediately.  This has the advantage of allowing the origin to try another
* path in the case where it was attempting a path switch.

(2) Reuse of RTP connections (Figures 9-3, 10-2, 10-3, 10-4)

There seem to be problems with the reuse of an RTP connection in the reverse
of the original setup direction.  In order to reuse a connection, the RSCV
has to match (plus other conditions - see Condition A of figures 9-3, 10-2,
10-3 and 10-4).  This means that the destination has to reverse the RSCV
received on the first BIND to flow on an RTP connection in order to compare
it with RSCVs of BINDs flowing in the opposite direction.  Unfortunately, this
is not possible, since the destination node does not know the origin node-
name.  Effectively, this means RTP connections cannot be reused in reverse.

Have we missed some part of the protocol, or is this an issue?

* Good question.  The "RSCV" (actually a series of CV 46's) describing the
* reverse path is sent on the Connection Setup message to the destination.
* It is carried in RTP Routing Information Segment (page A-15) in the
* HPR Return Route TG Descriptor CV X'85' (page A-23).